Demos
Getting Started
One of the reasons I tried to write a tutorial is because it's a fine way to structure your mind while programming. Isn't that what programming is about? As I didn't receive any comments on my earlier Poker article [Developing a Poker Game], I'll try again. My English is not good enough to discuss things in depth, so I decided to send the code with as many comments as I could place. These comments should help you to easily expand and further develop the game. Download the game from the Newsletter Zip archive. [Editors Note: You are going to want to download the game with the newsletter and have it open (or printed) as you work through this article.] This Poker game is playable. It's not smart. I'm no poker player and I had to learn the rules of the game first.
Here is a model of how one might write a simple poker game program.
GOSUB display player hand
GOSUB display computer hand (face down)
[play]
GOSUB get computer bet
GOSUB get player's hand
Test for folds
Test for calls
If fold GOTO end
If call test for firsthand GOSUB get new hands ELSE GOTO compare hands
GOTO [play]
[new hands]
GOSUB evaluate computer hand and place computer bet
GOSUB get player bet
[compare hands]
Evaluate computer hand and player hand
GOTO are there winners
>
Of course this isn't the way to program in LB. Liberty Basic is event driven, so you have to consider using buttons to scan, input and wait. I made the program as intuitive as I could. Whenever possible, I programmed in modules. Numerous GOSUB's are used, so the flow of the game can easily be observed.
[nxtn] gosub [playersPlay] 'nxtn = player's next turn
WAIT
[cnxtn] gosub [computersPlay] 'cnxtn = computer's next turn
goto [nxtn]
WAIT
The gosub [computersPlay] ends with gosub [displayButtons]. Some buttons guide you, such as triggering the next player's turn. Other buttons, like the DEAL button, are hidden when not needed. The CALL and FOLD buttons are shown at every player's turn.
It's no problem to write an AI (artificial intelligence) routine for bluff poker. The hands are examined, evaluated and then weighted as follows:
The variable A holds the maximum number of bets the program will place before checking your hand. Here is a summary of the output of drawings from the poker program I made last time derived from every 100.000.000 hands the program gave me:
So to get a Royal Flush at the first deal is a one in a million chance. But the chance to get a pair is 46% and to get only a High card is 41%.
Here is the tricky part. Suppose you don't have a reasonable hand. By unreasonable, I mean a hand with A = 0 so to speak. You could easily say "CHECK". But, this is bluff poker so put on your poker face and takes a gamble. My program will place a bet in 10% of the cases even without a high card.
While you're looking at the code, please take a look at the various ways I programmed the messages on the screen. First of all you need the background from the screen (GETBMP) to place a message on the screen and then hide your message afterwards. It's not possible (at least I don't know how) to copy a piece of the screen before the controls (buttons) are placed. I had to clear all texts before reprinting, because new messages can be longer than the existing ones on the screen, making clearance a necessity.
The green screen was created with Photoshop. Only the Gradient tool and the fonts were needed. Other fonts I made with Microsoft Word. Next figure shows some tests for mixing metallic parts with the green screens used with this type of games (casino games). The third figure shows coins used for betting.

Let's compare a near flush with a pair. For example, what is the chance of getting a flush, if you already have four cards of the same suit? The number of remaining cards is 42, so the probability is (13-4)/42, meaning about 22%. But wait, your opponent could have some of those same suits, slimming your chances even more to as low as 14%. If you change only one card, the chance of getting a pair is at most 3/42 (7%).
The chance to have a pair is 46% and a pair is a higher start than four cards of the same suit. What are the chances of getting something better? The likelihood of getting another rank card that accomplishes the pair to make a three of a kind is maximum 2/42, about 4%. As you take three cards this makes 12%. Mind you that a flush beats a three of a kind. You need at least a full house to beat a flush. Keeping a pair is always better than trying to get a pair by shifting only one card. So my program will keep any pair higher than ten and take no chance to complete a near flush. Even though there is no need to drop a card when you have a four of a kind, the program will drop the odd card. This way the program tries to mislead you. The program will also play low profile in some cases where it has a strong hand. I could go on reasoning this way for hours and I'm not even sure I'm not simply mistaken. That's why I don't play poker.
As I stated before, the hardest part to program was the interaction between human and machine. Of course, I have an aversion to use those prompts. The best interaction is one where the player only uses his mouse. Instead of using the number keypad, I created the coins.
And then there comes the time when you have to answer a bet. Now there are smart guys constantly starting their betting high while putting on their poker faces. Maybe you'll need to design some pattern recognition here. Otherwise the computer will gradually lose. So, to answer a bet placed by your opponent will take some more AI to work with. If the opponent places a bet, the program will need to decide if it wants to continue playing the current hand. That's why I made subroutines to consider the chances of getting a better hand after dropping and drawing extra cards. I made some NEAR FLUSH and NEAR STRAIGHT routines. The listing is chock full with remarks to make it easily understandable.
The most important piece of code is the EVALUATENEXTBET of the computer. Most of the computer's Artificial Intelligence is settled at the COMPUTERNEXTBET part of the code. After the choice is made for getting a new hand or just folding, the COMPUTERNEXTBET follows. Based upon the hand, the computer will keep bidding until it has to check the hand. If however the player takes the initiative and raises the bidding then the computer gets in trouble. The current routine lacks pattern recognition or identification of other clues to guess if the player is bluffing.
The variable tChance stands for "take chance." The variable raise indicates the weight of the bet. It is also a consideration or measurement to take a chance.
I guess that my game still has some bugs. Debugging took most of the time I spent on this game. It still lacks the sound routines and the sprites I intended to write, but I stopped and started working on other projects.
I hope you will enjoy the game. I hope you will improve it if you can.
Gordon Rahman
[Editors Note: Don't forget the game is in the files area of the newsletter download - enjoy!]